…alls

An interactive http install could silently skip asking the operator for the
shared auth token (MCP password) when one was already sourced from
MCP_AUTH_TOKEN env, a flag, or the tunnel collector, writing the agent config
with a credential the user never chose or saw.

Add an explicit, always-run "MCP Password" step to the install wizard for
http/remote installs in interactive mode: it shows whether a token already
exists, lets the operator keep it (Enter) or type a replacement (masked), and
fails if a public endpoint would be written with no password. Non-interactive
installs still source the token from flags/env without prompting.

The MCP Password step updated only the in-memory token used for the agent
config's Authorization header. When the operator replaced the password on an
install backed by a managed service, the running endpoint kept enforcing the
inherited MCP_AUTH_TOKEN from the service env file — so the agent pointed at a
credential the server rejected. Now the new password is also persisted to the
service env file and mirrored on the service state, keeping the endpoint and
the agent config on the same credential. Keeping the existing token needs no
propagation.

Persisting the new MCP_AUTH_TOKEN to the service env file is not enough on its
own: the running endpoint only reads it at process start, so it kept enforcing
the old token while the agent config used the new one. Restart the managed MCP
service after writing the new token so the live endpoint reloads it and the
connection keeps working. The restart seam is wired only in production and only
when the install is actually backed by a managed service (--service=false,
operator-run servers, and tests skip it).

Two correctness fixes to the MCP password change path:

- Thread the caller's context through RestartManagedService (and the restart
  seam) so an interrupted interactive install (Ctrl-C) can cancel the service
  restart instead of it running on context.Background().

- Order persistAuthToken so a failed restart cannot leave a mismatch: the new
  token is written to the env file (the restarted process reads it at boot)
  and only committed to state AFTER the restart succeeds. If the restart
  fails, the env file and in-memory state are rolled back to the token the
  still-running endpoint actually enforces, so disk, memory, and the live
  endpoint agree. Covered by TestMcpInstallHTTPPasswordRestartFailureRollsBack.

If the managed service restart fails, the MCP password change rolls the env
file back to the token the still-running endpoint enforces. The previous code
swallowed the restore-write error, so if the rollback itself could not be
persisted the disk file silently kept the uncommitted new password while state
used the old one. Now a failed restore write is combined into the returned
error instead of masked. Covered by
TestMcpInstallHTTPPasswordRestoreFailureSurfaced.

TestMcpInstallHTTPPasswordRestoreFailureSurfaced forces a failed rollback
write by making the env file's directory unwritable (os.Chmod on a dir), which
Windows does not honor, so on Windows/arm64 the restore write succeeded and the
test failed expecting the surfaced restore error. Skip the dir-permission
trigger on Windows; the rollback/restore-failure surfacing itself is
OS-independent and remains covered on all platforms by
TestMcpInstallHTTPPasswordRestartFailureRollsBack.